1. Field of the Invention
The present invention relates generally to streaming video content to a networked client device. More particularly, the present invention relates to determining an optimum bandwidth for a networked client device.
2. Background Art
When a networked client device streams video content from a server, the server must send adequate packets to the networked client to ensure a smooth viewing experience without any stutters. Based on the client device's available bandwidth, the server can calculate an adequate bit rate to stream video without interruptions. Presently, there are several methods for a server to calculate a proper bit rate.
One approach requires a user to select a bit rate, based upon user knowledge of the client device available bandwidth. The major drawback to this approach, however, is that the user must be sophisticated enough to choose the best bit rate in order to stream video without interruptions. To overcome this drawback, many implementations give the user a limited set of bit rate choices, such as a broadband option and a dial-up option. Because of the limited choices, the user may not be able to choose the most efficient bit rate available for that user's client device. In addition, the available bandwidth may fluctuate depending on network conditions. The user may not be aware of such fluctuations or other changes to the available bandwidth. For example, the user may be using a smartphone and move from an area with faster 4G coverage to an area with only 3G coverage. Moreover, the network itself may suffer from outages or congestion, which may significantly impact the available bandwidth. This may result in the user, for example, unknowingly selecting a bit rate which exceeds the available bandwidth. The network may also improve, for example from hardware upgrades or reduced congestion. The user may select a bit rate which does not fully utilize the available bandwidth. Moreover, this approach typically results in the user being prompted to select a bit rate again at the start of a different stream.
In another approach, the client device first downloads sample data before beginning the stream, typically in a hand shake session. Based on the time required for the client device to download the sample data, the server will determine a bit rate. Because the bit rate is based upon actual network conditions at the time, the bit rate may be more accurate than a bit rate based upon a user selection. Although this approach may address the problems associated with user-selected bit rate determination, the initial downloading of the sample data may introduce delays before the actual stream begins. The client device must first download the sample data before the server knows at what bit rate to stream. In addition, the bandwidth available to the client device may change from that indicated by the initial sample data download. In other words, the sample data may have been downloaded at a time when the available bandwidth was particularly higher, or lower than average. For instance, the sample data may have been downloaded at night, when network traffic may be less congested than usual.
In yet another approach, the server may use an adaptive bit rate. As the stream is being delivered, the bit rate is adjusted according to changes in the available bandwidth of the client device. The adaptive bit rate is capable of accounting for bandwidth fluctuations or changes, unlike the previously mentioned approaches. However, the adaptive bit rate requires a starting point. Consequently, the adaptive bit rate solution tends to err on delivering the lowest or highest available quality of stream. When the quality of stream is too high, the server typically sends packets that do not reach the client device in time. The client device must then buffer or cache parts of the stream in order to accumulate enough packets to display an uninterrupted segment of video. However, this buffering results in pauses or delays which interrupt the stream. Conversely, when the quality of stream is too low, the server is not sending as many packets as the client device is capable of receiving. The stream itself does not need to pause for buffering, but the picture quality is unnecessarily degraded. As a result, the user is unable to obtain the highest quality stream available, although the picture quality may improve over time as the bit rate adjusts itself. By constantly adjusting the bit rate, an adaptive bit rate may eventually reach a suitable bit rate. However, the initial stream may suffer from delays or degraded quality and the user does not instantly get the best possible stream. Subsequent streams may require reapplying this process.
To improve streaming performance, these approaches may be combined. For example, an adaptive bit rate may start at a bit rate derived from a user selection. Although the adaptive bit rate may adjust itself for bandwidth fluctuations, the initial determination of a bit rate suffers the same drawbacks of a user-selected bit rate. Additionally, the initial bit rate may be improved by utilizing sample data to calculate a bit rate. However, downloading the sample data causes a delay before the actual stream may begin. Furthermore, a subsequent stream may require repeating the entire process.
Accordingly, there is a need to overcome the drawbacks and deficiencies in the art by providing a solution enabling a substantially immediate determination of the optimum bit rate at which to communicate with a networked client device, so as to initially stream the highest quality video possible without delays.